FIG. 1 illustrates a portion of an exemplary prior art service provider network 20 for providing Triple Play services to service subscribers. A residential gateway (RG) in a service subscriber's residence 50 marks subscriber traffic before sending it off to a Digital Subscriber Line Access Multiplexer (DSLAM) 100 to which it is connected via a local loop 102. Typically, each of Voice over Internet Protocol (VoIP) traffic, television (TV) broadcast or video on demand (VoD) traffic, as well as high speed internet traffic are uniquely marked to distinguish each service from other traffic. Marking the traffic enables an Ethernet Service Switch 104 to provide proper quality of service (QoS) for each type of traffic and to direct each type of traffic to the appropriate systems in the network.
There is generally one residential gateway (RG) 106 and one DSLAM 100 port per service subscriber residence 50. When traffic exits through the DSLAM, a Virtual Local Area Network (VLAN) ID is assigned to each traffic flow from each subscriber. At the Ethernet Service Switch 104, one Service Access Point (SAP) 108 is provisioned per subscriber. The Ethernet Service Switch 104 divides the traffic into flows on a per subscriber basis according to the type of traffic and sends the traffic flows to their respective destinations (e.g., application servers 132 via service routers 130) in tunnels through the service provider network. A deep packet inspection (DPI) component 110 monitors traffic to detect viruses, monitor Quality of Service (QoS) per subscriber flow, and perform similar functions. The Subscriber Service Controller (SSC) 112 includes a Dynamic Host Configuration Protocol (DHCP) Server 114 for assigning Internet Protocol (IP) addresses to the RGs 106 at their request, and a Policy Manager 116 applies policies to the various Triple Play services and service subscribers.
Elements of the service provider network are managed using an Element Management System (EMS) 124, which stores network element information in an EMS database 126, in a manner known in the art.
The Triple Play subscriber and policy management system (SSC) 112 requires complete information about all resources used by a subscriber to provide monitoring and management of Triple Play Services for the subscriber. However, this information is scattered throughout multiple entities in the customer network and operations support system (OSS) 118—e.g. the RG (residential gateway) 106 used by the subscriber, the DSLAM 100 port assigned to the subscriber, the SAP (Service Access Point) 108 assigned to the subscriber, the aggregating Ethernet service switch 104 serving the subscriber, etc. Further compounding this problem is the number of subscribers that need to be supported, which can be up to 17 million subscribers per SSC 112.
Consolidating this information in the SSC requires complex software that is difficult to design, expensive to develop and must include modules to pull the information from other OSS components, such as a customer lightweight directory access protocol (LDAP) database, a subscriber provisioning system 122 and/or an inventory database.
Alternatively, it has been proposed that modules be developed in other OSS components to push required information to the SSC 112. Either approach, however, requires the development of almost N**2 software modules to facilitate information exchanges between N OSS software components.
It is therefore highly desirable to provide a less complex way of capturing service topology information needed by a Subscriber Service Controller for IP address assignment, policy management, etc. in the provision of Triple Play services.